有了 Storage system, Database 和 API Service 後, 我們已經可以讓 客戶端 (Web, Mobile, 第三方服務, 其他內部服務等等) 操作我們的資料了 🎉
這些元件是大部分系統必要的部分, 基於這些元件 (或服務) 可以再根據需求衍生出各種變化
比如: 可靠性 (Reliability), 可用性 (Availability), 一致性 (Consistency), 分區容錯性 (Partition Tolerance), 擴展性 (Scalability), 延遲性 (Latency) 等等
為了達成上述目標, 我們需要調整 資料模型 (Data Model), API 設計 等等
也會衍生很多困難需要克服, 這些留待本系列後面再說~
接下來兩天介紹的元件: Notification 和 Email, 由於不是系統必須, 所以僅介紹有哪些第三方服務可以用
有時間再補充一些小知識
今天來講 Notification Service
如果覺得上篇介紹的 API Service 很無聊, 今天就可以現學現賣了XD
由於 "通知" 都是從 伺服器 發起, 就可以使用 Server Push 的技術!
比如昨天提到的資源監控系統, 股票價格通知, 聊天訊息通知 等等
(這邊指的是 "即時" 通知, 或叫做 Push Notification)
(若是像論壇的通知訊息, 比如 IT 邦幫忙 的小鈴鐺, 不一定要做到 Server Push, 可以走 Request-response 架構, 等使用者發出請求再檢查就好, 沒有實驗過他們的規格囧)
不過我們今天以介紹元件為主, 所以我們的 伺服器 會透過 第三方服務 通知使用者, 就不需要 Server Push 了~
根據通知的 "媒介" 我們可以分為
可以透過傳統的 Email Protocol 像是 SMTP, POP3, IMAP 等來收發信件
只需要架設 SMTP Server 就可以寄信了
但是! 如果我們想要 "讓使用者收到" 會非常麻煩
因為多數主流的 電子郵件供應商 如 Gmail, Yahoo mail, Outlook 等都會 過濾 和 分類 釣魚信, 垃圾信 等等, 還要符合 網路服務供應商 的規範
否則容易被歸類為 垃圾信件, 標示成釣魚信, 甚至 直接被隱藏!
這需要我們另外處理, 細節等明天再介紹~
所以, 與其自己架 SMTP Server, 不如用下面幾個第三方服務吧XD
其中 SendGrid 和 Amazon SES 是最多人用的, 詳情請自行至官網了解
自架簡訊服務又比 Email 更麻煩了 (個人覺得)
要購買 GSM (Global System for Mobile Communication) 和 SIM 卡, 並安裝 Gammu 和 smstools
和 Email 類似, 要符合 電信營運商 規範, 避免被當成詐騙簡訊, 且每日有訊息量上限
目前市面上手機作業系統主要是 Android 和 iOS, 有以下兩種
值得注意的是, FCM 和 APNS 是用在 "簡訊推送", 如果是要 "收發簡訊", 有以下幾種選擇
瀏覽器有提供 Web Push Notification (WPN) API, 可以讓網站 "主動" 通知使用者
好處是不像 Email 和 簡訊 那麼複雜又要符合一堆認證和規範, 只要使用者允許接收通知就行
(這就是某些部落格一進去就會彈出來的小視窗)
缺點是這是 "客戶端" 的解法, Push Notification 是透過 Service Worker 發送
如果要由 伺服器 通知, 就需要建立 Service Worker 和 伺服器的連線
但是瀏覽器為了節省資源, Service Worker 閒置太久很容易死掉, 所以需要定時送 Heartbeat 給 伺服器
或是自己處理斷線重連等等, 也是很麻煩
適合 新聞網站, 電商網站物流追蹤 和 論壇網站通知 等情境
iThome鐵人賽
看影片追技術